home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19941031-19941221 / 000457_news@columbia.edu_Fri Dec 16 13:48:52 1994.msg < prev    next >
Internet Message Format  |  1995-07-31  |  4KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01165
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 16 Dec 1994 23:30:21 -0500
  3. Received: by apakabar.cc.columbia.edu id AA19182
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 16 Dec 1994 23:30:18 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MS-Kermit running under Windows trbl
  9. Message-Id: <1994Dec16.194852.35622@cc.usu.edu>
  10. Date: 16 Dec 94 19:48:52 MDT
  11. References: <D0wsAs.6vv@nntpa.cb.att.com>
  12. Organization: Utah State University
  13. Lines: 57
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <D0wsAs.6vv@nntpa.cb.att.com>, mrbaker@hodcs.ho.att.com (-M.BAKER) writes:
  17. > Hi:
  18. > 
  19. > We are currently using MS-Kermit (Beta 14) to communicate with a UNIX
  20. > system, both directly from the DOS prompt as well as run from Windows.
  21. > I have packet driver 3C5X9PD and shim WINPKT doing the networking
  22. > honors.
  23. > 
  24. > The problem is that when someone telnet's to the UNIX system from
  25. > Windows (i.e., they have an icon for MS-KERMIT, using the .PIF
  26. > distributed with MS-KERMIT) everything works fine until they minimize
  27. > it and leave it alone for a while [still trying to measure exactly what
  28. > "a while" is -- seems to be a half hour or hour or so].  Then when they
  29. > return to MS-KERMIT, it is 'asleep'.  The TCP-IP connection no longer
  30. > seems to be working (no response to the UNIX shell prompt, no response
  31. > to the Telnet Are-You-There) yet the UNIX system still thinks the
  32. > connection is up.  I've tried running with SET TELNET DEBUG-OPTIONS ON
  33. > looking for clues, but no luck.
  34. > 
  35. > The only mentions I could find in the documentation is in the .BWR file.
  36. > Section 4 (Microsoft Windows) suggests changing the .PIF to raise
  37. > Kermit's priority, lock it in memory (even though the WINPKT docs
  38. > say this shouldn't be necessary), and make sure some background time
  39. > is allocated.  I've played with these the best I could with no apparent
  40. > luck.  It does have the caveat that Kermit is at the mercy of other
  41. > apps. anyhow.
  42. > 
  43. > When I run MS-Kermit right from DOS (no Windows), it works just fine
  44. > even overnight so I'm pretty sure the indigestion is coming from Windows.
  45. > 
  46. > Would appreciate hearing from others who have run into this, have ideas,
  47. > etc. worth trying in order to minimize (if not eliminate) this problem.
  48. > Private email to mrbaker @ hodcs.att.com, or postings to this group
  49. > would be most welcome.
  50. --------------
  51.     Ok. I tried your situation here over the past 45 minutes. MSK 3.14
  52. beta-15 running in Windows as an icon, using ODIPKT+WINPKT over the current
  53. Novell ODI material. I logged onto my Unix machine with Kermit, shrunk MSK
  54. to an icon, and went away to speak with WordPerfect/Windows for the duration.
  55. After that 45 minute interval I enlarged the icon to a window and the
  56. connection was just fine.
  57.     A couple of guesses to make here. First, is your lan adapter's
  58. shared memory protected against all memory managers (DOS and again in
  59. Windows)? If not then Windows could be using that memory for other purposes
  60. and the lan adapter can become wedged or worse. An intermediate test, after
  61. you've exclude='d both sides, is to start another Telnet session with Kermit.
  62. If a new session starts ok then local comms are in working order.
  63.     Second, the lan adpater part of things may not be especially strong
  64. to begin with, and when it's not serviced often packets overwhelm it and it
  65. wedges. If there is an IRQ conflict (lan adapter sitting on IRQ 3 along with
  66. serial port COM2, for example) then the adapter can be squashed by the
  67. competing hardware and/or Window's drivers.
  68.     The option to "fix task in memory" is needed if you are not using
  69. winpkt with a Packet Driver. Go get mine, the two argument variety, from
  70. netlab2.usu.edu, cd drivers, file winpkt.zip, and give it a try. I don't fix 
  71. tasks in memory (absent minded Professor).
  72.     Joe D.